Krzywe cykli technologicznych wznoszą się i opadają. Nieuchronność tego zjawiska ilustruje wiele teorii, jak choćby koncepcja przełomowych innowacji z krzywą „S”. Technologie Chmurowe podlegają tym samym prawom. W ciągu ostatnich dziesięciu lat obserwowaliśmy silne trendy wznoszące i wydaje się, że dla chmury nadchodzi kolejna fala.
Pierwsza fala wznosząca dla chmury to czas, w którym organizacje zachłysnęły się technologią kuszącą perspektywą obniżenia kosztów i wzrostu elastyczności biznesowej. Wraz z rozwojem tej technologii i wzrostem zainteresowania, dostawcy zaczęli różnicować swoje usługi i specjalizacje.
AWS stał się napędem dla eCommerce doskonałym dla aplikacji, które muszą integrować się z ekosystemami handlowymi. Platforma Azure, idealna do obsługi aplikacji utworzonych z użyciem technologii i narzędzi Microsoft, zagospodarowała obszar aplikacji tradycyjnych i opartych na bazach danych. Google, obsługujący najnowsze protokoły i platformy, zachęcał do eksperymentowania i innowacji.
Ostatecznie doprowadziło to do powstania drugiej fali wznoszącej dla chmury. Na tym etapie powstały najpopularniejsze obecnie środowiska wielochmurowe. Dostawcy usług wyspecjalizowali się w różnych aplikacjach, a organizacje zaczęły wybierać „odpowiednią dla danej aplikacji chmurę”. Dzisiejsze typowe przedsiębiorstwo, zgodnie z raportem F5 o stanie usług aplikacyjnych, obsługuje aplikacje w średnio od dwóch do sześciu różnych środowiskach chmury publicznej.
Organizacje, które od jakiegoś czasu działają w chmurze, zaczęły buntować się przeciwko jej znacznym kosztom operacyjnym, mogącym obniżać marże zysku i negatywnie wpływać na nastroje inwestorów. Zjawisko, często określane jako „repatriacja do chmury”, polegające na wyprowadzaniu się z przestrzeni publicznej z powrotem do centrum danych i chmury prywatnej[1] dotyczy sporego odsetka dużych przedsiębiorstw[2] i rozpoczyna kolejną, trzecią falę dla chmury.
U podstaw tych zmian leży troska o koszty. Organizacje chcą maksymalizować zwrot z inwestycji w aplikacje. W miarę przechodzenia przez kolejne fazy cyfrowej transformacji[3] liczba aplikacji w portfolio przedsiębiorstw rośnie. Koszt staje się istotnym czynnikiem hamującym rozwój możliwości cyfrowych, których oczekują konsumenci. Każda aplikacja musi przynosić korzyść w postaci wzrostu produktywności lub zysku.
Czynnik kosztowy jest znaczący, gdy badamy portfolio aplikacji korporacyjnych i zauważamy, że większość aplikacji w chmurze publicznej nie została zaprojektowana w sposób umożliwiający wykorzystywanie ekonomii skali natywnej dla modelu chmury. Wynika to z tego, że większość obecnie obsługiwanych aplikacji opiera się na tradycyjnych architekturach[4], a nie na modelu kontenerowym inspirowanym chmurą.
Tymczasem aplikacje opracowane przy użyciu nowoczesnych architektur z natury lepiej realizują oszczędności kosztowe obiecywane przez przetwarzanie w chmurze. Natywne dla chmury architektury koncentrują się bowiem na dezagregacji obciążeń w oparciu o funkcje biznesowe - na mniejsze, oddzielne funkcje, określane mianem mikrousług. Dzięki temu procesowi mają większą zdolność operacyjną do wykorzystywania ekonomii skali w chmurze. Wykorzystywanie zasobów aplikacji natywnej dla chmury w porównaniu z tradycyjną aplikacją jest skuteczniejsze ponieważ skalowane są tylko te funkcje biznesowe, na które jest zapotrzebowanie, a nie wszystkie z nich.
Z naszych doświadczeń wynika, że można zastąpić nawet 200 silosowych aplikacji pojedynczą mikrousługą, która spełnia adekwatną rolę biznesową.
Ponadto usługi aplikacyjne i architektury zdolne do działania w dowolnym środowisku chmurowym zapewniają płynniejszą migrację z jednego środowiska do drugiego.
Gdy organizacje polegają na spójnym zestawie usług aplikacyjnych – oddzielonych lub luźno połączonych z podstawową infrastrukturą – eliminują także istotne źródło kosztów związanych z przetwarzaniem w chmurze (narzędzia, usługi i umiejętności specyficzne dla danej chmury). Powyższe zalety pozwalają organizacjom na faktyczne wykorzystanie chmurowych możliwości i oferują znaczące oszczędności.
Rozważmy teoretyczny przykład. Weźmy przedsiębiorstwo z natywną aplikacją chmurową, której prototyp powstał w AWS. Deweloperzy włączają usługi aplikacyjne AWS, takie jak równoważenie obciążenia, zapora sieciowa (WAF) i Kubernetes Ingress. Aplikacja działa skutecznie, więc zostaje „uruchomiona” i zaczyna obsługiwać ruch oraz klientów w czasie rzeczywistym.
Następnie, wraz ze wzrostem funkcjonalności aplikacji, firma podejmuje decyzję, że jej część musi zostać wdrożona na platformie Azure. Ta sama aplikacja nadal wymaga równoważenia obciążenia, WAF i Kubernetes, więc zespoły programistów i DevOps muszą poświęcić czas na wdrożenie, skonfigurowanie i utrzymanie tych samych usług, jednak specyficznych dla platformy Azure.
Jest to dla przedsiębiorstwa etap doświadczenia pierwszych dwóch fal adaptacji chmury - przejścia do chmury w celu zwiększenia elastyczności, a następnie przejścia do środowiska multi-cloud. Wraz ze wzrostem doświadczenia firmy w zarządzaniu aplikacjami natywnymi dla chmury okazuje się, że rachunek kosztów będzie korzystniejszy, gdy aplikacja zostanie w całości lub części wdrożona lokalnie (on-prem). Oznacza to dla firmy trzecią falę cloud i wymaga kolejnej rundy wdrażania, konfiguracji i utrzymania lokalnych usług aplikacyjnych.
Jesteśmy przekonani, że dostawcy usług w chmurze przygotują się na zjawisko kolejnej fali cyklu, oferując atrakcyjne usługi i nowe korzyści ekosystemu, które zachęcą przedsiębiorstwa do ponownego wdrażania w chmurze publicznej. Zapoczątkuje to czwartą falę w cyklu technologicznym adaptacji chmury. Ostatecznie, prawie każda organizacja działa w przypadkowym modelu wielochmurowym. Spodziewamy się, że repatriacja chmury tylko przyspieszy wskazany trend.Niezmiennie korzystniejsza pozostaje strategia inwestowania w odpowiednie usługi aplikacyjne, aby zapewnić biznesowi możliwie najlepszą chmurę na przyszłość.
Lori MacVittie, Principal Technical Evangelist, F5
Link do strony artykułu: https://badaniamarketingowe.wirtualnemedia.pl/centrum-prasowe/artykul/trendy-w-chmurze-zmiany-w-cyklu-technologicznym